RE: [HACKERS] inlining
От | Henry B. Hotz |
---|---|
Тема | RE: [HACKERS] inlining |
Дата | |
Msg-id | v03130308b1a73bf1f186@[137.78.218.94] обсуждение исходный текст |
Ответ на | RE: [HACKERS] inlining ("Stupor Genius" <stuporg@erols.com>) |
Список | pgsql-hackers |
At 4:50 AM -0700 6/12/98, Stupor Genius wrote: >One comment...when you ran the tests in succession, could the cache be >responsible for the timing groupings in the same test? Should a >little program be run in between to "flush" the cache full of garbage >so each real run will miss? Seem to recall a little program, in CUJ, >I think, that set up a big array and then iterated over it to trash >the cache. Obviously I'm commenting at second hand, and perhaps this problem is handled properly, but: Many CPU's have independent data and instruction caches. Setting up a big array and moving through it will flush the data cache, but most benchmark anomalies are likely to be due to the instruction cache, aren't they? Also, if you have a process (program) stop and then restart is the OS smart enough to reconnect the VM state in such a way that the cache isn't flushed anyway? Can it even preserve cache coherence through a fork (when the VM state is mostly preserved)? I doubt it. That said if you are testing multiple SQL statements within a single connection (so the backend doesn't fork a new process) then I could see some anomalies. Otherwise I doubt it. Anyone know better? Signature failed Preliminary Design Review. Feasibility of a new signature is currently being evaluated. h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu
В списке pgsql-hackers по дате отправления: